前言

打鐵趁熱，整理了一部分最近開發上學到的事情，希望讀者不吝予以指教！

本文將介紹並深入比較兩種主要的 PostgreSQL 資料庫連線管理方式，在開發網站或應用程式時，如何有效管理資料庫連線是一個重要的課題，想像資料庫就像是應用程式的資料中心，我們需要建立連線才能存取這些資料，而連線的管理方式，就會直接影響到應用程式的效能、穩定性和資源使用效率。

方案一：連線池管理

主要由三個核心組件組成，讓我們逐一了解他們的功能和特點。

1. 連線池配置 (DatabaseConfig)

這是整個架構的基礎層，負責管理資料庫連線池的核心功能：

• 控制連線池的大小範圍
• 處理連線的獲取與歸還
• 提供初始化設定介面

from psycopg2 import pool

class DatabaseConfig:
    _connection_pool = None
    
    @classmethod
    def initialize(cls, minconn=1, maxconn=10):
        """初始化資料庫連線池"""
        if cls._connection_pool is None:
            cls._connection_pool = pool.ThreadedConnectionPool(
                minconn,
                maxconn,
                host="localhost",
                database="mydb",
                user="user",
                password="password"
            )
    
    @classmethod
    def get_connection(cls):
        """從連線池獲取連線"""
        return cls._connection_pool.getconn()
    
    @classmethod
    def return_connection(cls, conn):
        """將連線歸還給連線池"""
        cls._connection_pool.putconn(conn)
    
    @classmethod
    def close_all(cls):
        """關閉所有連線"""
        if cls._connection_pool:
            cls._connection_pool.closeall()

2. 上下文管理器 (Context Manager)

這是中間層，主要負責連線的生命週期管理：

• 自動處理資源的配置與釋放
• 管理資料庫交易的生命週期
• 確保資源在各種情況下都能正確清理

from contextlib import contextmanager
import logging

@contextmanager
def get_db_connection():
    conn = None
    try:
        conn = DatabaseConfig.get_connection()
        yield conn
        conn.commit()
    except Exception as e:
        if conn:
            conn.rollback()
            logging.error(f"Database error: {str(e)}")
        raise
    finally:
        if conn:
            DatabaseConfig.return_connection(conn)

3. 應用程式生命週期管理

這是最上層，負責將連線池與應用程式整合：

• 應用啟動時初始化連線池
• 應用關閉時清理所有資源

from fastapi import FastAPI
from contextlib import asynccontextmanager

@asynccontextmanager
async def lifespan(app: FastAPI):
    # 應用啟動時初始化
    logging.info("Initializing database connection pool")
    DatabaseConfig.initialize(minconn=5, maxconn=20)
    
    yield
    
    # 應用關閉時清理
    logging.info("Closing database connections")
    DatabaseConfig.close_all()

app = FastAPI(lifespan=lifespan)

使用範例

def get_user(user_id):
    with get_db_connection() as conn:
        with conn.cursor() as cur:
            cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))
            return cur.fetchone()

方案特點

1. 資源管理

   • 避免頻繁建立和關閉連線
   • 控制最大連線數，預防資源耗盡
   • 連線重複使用，提升效能

2. 自動化處理

   • 自動管理連線生命週期
   • 自動處理交易（commit/rollback）
   • 自動處理異常情況

3. 進階選項

   • 連線統計和監控
   • 斷線自動重連
   • 連線存活時間控制（TTL）
   • 連線驗證機制
   • 優雅關機處理

方案二：建立單一連線

簡單粗暴，適合剛學習資料庫應用的方法。

from fastapi import Depends
import asyncpg

async def get_database_connection():
    conn = await asyncpg.connect(
        host="localhost",
        database="mydb",
        user="user",
        password="password"
    )
    return conn

@app.get("/users/{user_id}")
async def get_user(
    user_id: int, 
    conn: asyncpg.Connection = Depends(get_database_connection)
):
    row = await conn.fetchrow("SELECT * FROM users WHERE id = $1", user_id)
    return row

方案特點

• 每次請求建立新連線
• 程式碼簡單直觀

方案比較與分析

1. 運行效能

• 方案一（連線池）：
  • 減少連線建立和銷毀的開銷
  • 連線複用提升響應速度
  • 適合高頻請求場景
• 方案二（單一連線）：
  • 每次請求都有連線開銷
  • 適合低頻使用場景
  • 連線數量難以控制

2. 資源管理

• 方案一：
  • 統一管理連線資源
  • 可設置最大連線數上限
  • 支援連線監控和統計
• 方案二：
  • 需手動管理連線生命週期
  • 資源使用較難預測
  • 缺乏集中管理機制

3. 程式碼複雜度

• 方案一：
  • 初始設置較複雜
  • 需要額外的管理程式碼
  • 使用時較為簡單
• 方案二：
  • 程式碼結構簡單
  • 容易理解和維護
  • 缺少完整的錯誤處理機制

4. 可擴展性

• 方案一：
  • 易於橫向擴展
  • 支援動態調整連線池大小
  • 可增加監控和統計功能
• 方案二：
  • 擴展性受限
  • 高併發時可能遇到瓶頸
  • 難以添加額外功能

5. 事務處理

• 方案一：
  • 內建交易管理
  • 支援嵌套交易
  • 異常處理更完善
• 方案二：
  • 需要額外實作交易邏輯
  • 交易控制較為基礎
  • 錯誤恢復機制有限

建議使用場景

方案一：

• 企業級應用
• 高併發系統
• 長期運行的服務
• 需要精細資源管理的場景
• 微服務架構

方案二：

• 原型開發
• 小型應用
• 低併發場景
• 簡單的 CRUD 操作
• 短期運行的腳本

點餐流程比喻

為了讓非技術背景的讀者更容易理解這些概念，我用點餐流程來比喻請求與資料庫之間的關係，想像一下當你走進一間麥當勞：

連線池管理（排隊櫃檯點餐）

有 1-5 個櫃檯：

• 每個客人依序到空的櫃檯點餐
• 點完餐的客人離開，櫃檯可立即服務下一位客人
• 尖峰時段可彈性增加（開放）櫃檯數量
• 客人永遠在櫃檯點餐，不會直接進廚房

特點：

• 流程有序且效率高
• 資源使用可控制
• 安全性高（廚房與客人分離）
• 可重複使用既有櫃檯

單一連線（直接進廚房）

沒有櫃檯，客人直接進廚房找餐點：

• 每位客人都要自己走進廚房
• 廚房空間有限，無法容納大量人流
• 現場容易混亂且效率低落
• 缺乏管理和控制

特點：

• 效率低（每次都要走進廚房）
• 資源浪費（無法重複使用通道）
• 安全風險（直接接觸廚房）
• 容易失控（沒有流程管理，無法應對大流量需求）

結語

選擇合適的連線管理方式需要考慮多個因素：

• 應用程式的規模和複雜度
• 預期的併發量
• 開發團隊的技術能力
• 維護成本

對於大多數生產環境的應用來說，使用連線池管理是更好的選擇，它提供了更好的性能和資源管理能力，就像麥當勞不可能讓所有客人直接進廚房一樣，資料庫存取也需要有序且受控的管理機制。反之，對於開發環境或簡單應用，建立單一連線在需要快速迭代的開發測試需求上可能更有優勢。